COMMENT ⊗   VALID 00004 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	difference between ai and cognitive ...  engineering versus simulation.
C00006 00003	What to do til the doctor comes?
C00008 00004	acm
C00013 ENDMK
C⊗;
difference between ai and cognitive ...  engineering versus simulation.


a little lisp as graphs 


--------------------------------------------
Future languages:

There are several difficulties with contemporary computational languages:

1. procedural, not declarative

2. too low level --patterns, graphs

3. cultural -- too dependent on the culture and society of the originator
	       (typically western)



1. we should be able to explain WHAT we want done, and let the machines to more
   of the detailed work. This is a "semantic notion" not syntactic. it is more
   than a compiler translating to machine code. or such form fillers as
   "the last word"  the ntion requires  understanding (not mind reading)

   traces in ai: pattern-directed invocation/ goal-directed computing.

2. we need to begin developing a "spoken" language. i.e. languages that express
   more, faster. consider the pain of having to deal with each other in written-
   only form, (consider having to speak to each other in perfect gramatical
   natural language). flexibility is needed. 

   furthermore "distance" is needed: we need to be able deal with abstraction;
   to compute with trees and dogs and airplanes, ... 

   hopeful signs here: object-oriented programming. graphical languages.

3. This is much more difficult. how do we begin to imagine a "culture free" 
   language. given all the technology (better: ignoring all the technology)
   where do you begin. are there universals. graphics? sounds? 

What to do til the doctor comes?

assuming that one believs that the current situation is hopeless, but 
hope is on the way, what can one do now?

1. don't learn to program. learn to think "algorithmically" --as psycholgists,
   you should find a reasonable wealth of material in the ai/psychology field.

   if you are interested in languages with staying power, and some substance,
   learn lisp.

   small group interaction --focused, finding knowledgeable people who will
   talk  (wccf) ieee. start sub-groups within own organ

   work from the top down (taking substantial field to machines) don't just
   hack.




--------------------------------------------
biblio

herbert simon's turing lecture CACM march 1976 
		article: university of chicago mag fall 81.

mindstorms

world challenge

weizenbaum

GEB

zen and the art

?Soul of a new machine --tracy kider?

lisp
 lisp --winston
 aip

 august byte 1979 lsp --1981 smalltalk
acm

let me outline where i see lisp's power to lie, and then show what an
"ideal lisp env" hould/shouldnot have:


1. exploratory programming
   ill-defined  large complex, subject to change and modification

includes ai as well as systems programming.

in systems programming the  issue has been assembly  language
   why: modification without re-compile (patch  and continue)

   analogous to ai


lisp as a systems language  ≡ lisp as an assembly language: it is.


an assembly language for a different kind of machine (tree-oriented)

	program structure is tree

	primitve data structure is tree  (arrays, stings, ...)

primeval ooze


the language is well-defined (ignore mathematical import --not the issue)

the issue is OS on small machines -- the os first, the smallness second


what do i want as an os. 

a. at least what i have at the "machine level" --debuggability and control
   here debuggability of objects.

    recognize, select and construct objects.

    construct ¬> os. storage management make new object
		 dynamic management of objects 

b. bookkeeping of "context"
    dynamic -hypothesizing: what happens if i change the world this way?

	artistic ve. hacking --dabbing, exploring
	
    static -my data is part of my context
	change context → change data ... seems obvious, but goes against the
	grain of existing os. the data tends to stay outside the context,
	at worse, global (a monolithic file system) 
	at best, a hierarchical file system.

	altenative: data is part of a context and we use a path to that context
	  to orient outselves. naming structure is local but contexts are
	  linkable.

	compare lisp: garbage collection of data => collection of contexts.

	therefore no file system : uniform address space, untile we know how
	to build better machine models (432)


points
   assembly language

   object management

   no file system as such

a programming environment


now the "small machine" question.

size
   sophisitication doesn't cost that much
    lisp's and tiny talk


    tlc strings, vectors, lists, functions, windows, and on this
      version  files.

     vm inside cp/m  why? caues its there and small (os? as small as posssble
	better as a library of routiines that you glue or discard at will --
	poor will)

	
speed
   faster that the basics (big shock!  mu-lisp)  on just the numeric stuff

   compiler even faster --
	

features
   emacs in lisp, compiler in lisp, good part of the system in lisp and
   more every day.


final
 dont do to micros, what we've done to mini's: copy maxi's
   don't timesahre a z-80

--------------------------------------------
analogies:

  an artist dabbing til he "gets it right"  --hacking

  a mathematician struggling to find a proof and then re-working the proof


software defies analogy

perlis: always top-down except the first time